>_
Terminal
© 2026 Diego Soria Ruiz. All rights reserved.
guest@dsr: ~
guest@dsr:~$ ./welcome.sh
guest@dsr:~$ cat 2025-10-26-Destripando drivers vulnerables metodología de rev 02e3b23650a6825bb671818799c094d4.md
Última modificación: 26-10-2025
Etiquetas: #CCN-CERT25

Destripando drivers vulnerables: metodología de reversing para BYOVD

Author: Francisco José Carot

Ponente: Fran (Timoperitor en KPMG)

Contexto: Charla técnica sobre el procedimiento completo de identificación, análisis y explotación de drivers vulnerables en Windows para tareas de post-explotación.

Contexto general

La charla cubre el concepto de Bring Your Own Vulnerable Driver (BYOVD), una técnica donde un atacante instala un driver legítimo pero vulnerable (firmado por Microsoft) para ejecutar código en modo kernel. El caso práctico se centra en el CVE-2025-0288 del driver BionetDRV.sys (Paragon Hardware Manager), que permite escritura arbitraria en memoria kernel. Todo el proceso incluye ingeniería inversa con Ghidra, desarrollo de un PoC y uso de la primitiva para eliminar protecciones del proceso LSASS.

Conceptos clave

  • Drivers como puente kernel-userland: Los drivers ejecutan en kernel con máximos privilegios y exponen funcionalidades a modo usuario a través de IOCTLs
  • Requisitos para BYOVD:
    • Driver debe estar firmado por entidad certificadora de confianza de Microsoft
    • Solo administradores locales pueden instalar drivers
    • Versiones vulnerables siguen siendo instalables hasta que caduque la firma
  • Por qué usar drivers teniendo admin: Aunque seas admin/SYSTEM, sin driver no puedes manipular objetos del kernel directamente (tokens, callbacks de EDR, estructuras de procesos protegidos)
  • Identificación del objetivo: Usar bases de datos como lod-drivers.com para encontrar drivers vulnerables con CVEs recientes
  • Verificación pre-despliegue: Comprobar que el driver no sea detectado por el EDR del cliente en laboratorio
  • CVE-2025-0288 específico: Permite escritura arbitraria en kernel por mala gestión de memmove(). El IOCTL 0x220014 mapea contenido de RAM al espacio de direcciones del sistema

Desarrollo técnico

El procedimiento de ingeniería inversa empieza importando el binario del driver en Ghidra y aplicando análisis automático. La clave está en localizar tres puntos: el DriverEntry (equivalente al main), el enlace simbólico que permite comunicación desde userland, y la función que gestiona IRP_MJ_DEVICE_CONTROL (donde se procesan los IOCTLs).

Para mejorar la legibilidad del código desensamblado, hay que importar símbolos del kernel de Windows compatibles con Ghidra y retipar manualmente funciones clave como DriverEntry. Una vez localizada la función de control de dispositivos, aparece un típico switch-case que evalúa qué IOCTL se recibió y ejecuta la función correspondiente.

La vulnerabilidad del CVE-2025-0288 permite controlar tres parámetros críticos: página de RAM a leer, cantidad de bytes y dirección destino en kernel. Esto abre dos vectores de explotación: volcar toda la RAM a espacio accesible o sobrescribir valores críticos del sistema (como protecciones de procesos).

Herramientas y comandos mencionados

  • Ghidra → Desensamblador usado para análisis de binario del driver
  • IoCreateDevice / IoCreateSymbolicLink → APIs de kernel para crear objeto device y enlace simbólico
  • CreateFileW → API Win32 para abrir handle al driver desde userland usando el enlace simbólico
  • DeviceIoControl → API para enviar IOCTLs al driver con buffers de entrada/salida
  • NtQuerySystemInformation → API nativa (pre-24H2) para leak de direcciones kernel, ahora requiere SeDebugPrivilege
  • Beacon Object File (BOF) → Formato usado para ejecutar el exploit desde C2 (Cobalt Strike)

Términos técnicos importantes

  • IOCTL (Input/Output Control): Códigos que las aplicaciones envían al driver para ejecutar funcionalidades específicas
  • IRP (I/O Request Packet): Paquetes intercambiados entre modo usuario y kernel durante comunicaciones con drivers
  • Device Object: Objeto del kernel que representa al driver en el sistema operativo
  • PPL/PP (Protected Process Light/Protected Process): Mecanismo de Windows que protege procesos críticos como LSASS limitando los permisos de acceso
  • Major Function: Vector dentro del driver object donde cada posición mapea un tipo de IRP a su función gestora

Conclusión

Lo más interesante de la charla es el flujo completo: desde identificar un driver vulnerable en bases de datos públicas hasta tener un exploit funcional para post-explotación. El caso de eliminar protección de LSASS es especialmente útil porque demuestra cómo un driver permite hacer cosas que ni SYSTEM puede (leer memoria de procesos protegidos).

Puntos clave que me llevo:

  • La firma de drivers es el único control real, por eso BYOVD funciona
  • Versiones antiguas de drivers siguen siendo válidas años después de parchear el bug
  • A partir de Windows 11 24H2, leak de direcciones kernel es más complicado (necesitas SeDebugPrivilege o buscar 0days)
  • La primitiva de escritura arbitraria + leak de direcciones = game over para protecciones del sistema

Más

  • Profundizar en estructuras internas del kernel de Windows (EPROCESS, tokens, callbacks)
  • Estudiar otros CVEs de drivers vulnerables publicados en lod-drivers.com
  • Practicar reversing con retos de HackTheBox para mejorar lectura de código desensamblado
  • Investigar alternativas actuales para leak de direcciones kernel post-24H2
  • El ponente mencionó encontrar un 0day para bypass del requisito SeDebugPrivilege → buscar técnicas similares

<< cd ..

>_